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The RND(X) and RND(-X) 

By James E. Kupperian 

We all know that Microsoft BASIC V3.1 
returns a randcm number 'oetween 0 and 
.999,999,999 when one calls RND(positive 
number). Many know that it returns the 
last random number when we call RND(O). 

But what happens when we call RND(negative 
number)? 

The answer is single: Microsoft BASIC 
uses the negative nunber to produce a new 
seed, and returns the first random ni.snber 
of the series produced with this seed. 

Its power lies in the ability to produce a 
known random sequence or, conversely, if 
an unknown seed is used, an unknown 
sequence of randan numbers. 

This last observation is significant 
because the "random" sequence is only 
pseudo-random, generated successive 
wiltiplication, additicai, and normalizing 
<^)erati(xis to produce the "randan" 
nunbers. Thi^ it is governed by tiie 
initial oonditicHis, and v^en a prior 
conditicxi c*)tains (not necessarily the 
initial condition), the series will 
r^at. The lengtJi of this repeat will 
depend on the initial choice of tte 
multiplier and the additive constant. 

•me values supplied by Microsoft are 
poor. (See G. A. Stitton, PEEK(65), 
Novanber 1980). 

You might ask vrfiere we get the unknown 
seed. Right in 65D! Locaticffi 8996 is 
incranented by the keyboard polling 
routine. By PEEKING this location and 
ocMiverting it to a proper seed at the 
beginning of a program, one of 256 
"randOT" sequences can be selected. 

Wiile this is good for game players, 
what about applications programmers? 

There are numerous statistical uses for 
repeatable randan sequences. However, 
since file handling is of more general 
interest, I have written a simple hashing 
demonstration program to assign a number 
to an alphanumeric strir^. This number 
c^ be used to store and recall data in a 
random file, 

continued on page 2 


That Compiled Basic 

A welcome letter fixm Mike Epperson, 

Rt. 1, Box 25, Treviliafts, VA 23170: 

In answer to your question about the 
Pegasus B.ASIC compiler, I have this 
information to add to any more you may 
receive: 

BAD POINTS: 

( 1 ) There is no "INPUT" statement, I 
don't know why Pegasus chose not to 
inclement this feature, as it is fairly 
easy to use the inpxit subroutine built 
into the BASIC interpreter (the ccmpiled 
programs are designed to run with the 
BASIC interpreter resid«it in memory). 

(2) You can cxily use imsigned integers 
in the rar^e from 0 to 65535; no reals. 

(3) The canpiler ocoipies memory in 
the BASIC interpreter's area. After using 
the ocmpiier the Interpreter must be 
recalled to maiory. This can be a 
nuisance v^Aien you're developir^ and 
ddsugging your programs. 

(4) I had a problem with the 
instruction manual, This was only a minor 
problem, and if I had been real careful I 
probably would not have had it (I forgot 
that color memory is stored in 4-bit 
nibbles and tried to store a compiled 
program there. In the Pegasus manual they 
give an example in Oiich a progran is 
^^^^pil®d to $E000, They must have used a 
different type of system. I hwe a 
C8P^F.) 

(5) No string functions (MID$, 
concatenation, CHR$, etc.) CHR$ can be 
used, txit only with a print statanent, 

(6) Other statements, ccmmands, and 
functicHis not supported yet: 

ABS ATN CI£AR CONT COS CATA 

DEF EXIT EXP FN FRE I£N LIST 

ICG NEW NULL CW POS READ 

RESTORE RND RUN SOSI SIN SPC 
SQR STEP STOP TAB TAN TO USR 
VAL l^IT 

good POINTS: 

( 1 ) As expected, the compiled program 
riBis much faster than the interpreted 
BASIC program. The OTie program that I 

continued on page 7 
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The demonstration program does not But that is another subject. I would 

address collisions in a significant way. be interested in hearing ^bout other uses 

Incidentally, hashing is a method used to for RND(-X), 

distribute a non-random set to file space 

in a uniform way, thus making efficient James E. Kupperian 

use of space while preserving access 

speed. 

ProGram for UEinci OSI random seeo 
10 V=:P£EK<S996) IY~1/CY+1 > + .0123'^! V=RNDi-Y) 

•^rocram to demonstrate? usinci RND(-X) for hashanG 


1© 

20 POKEe03.^» i 30 

30 : CHANGE ADDITIUE CONSTANT 

^30 PR I NT i INPUT" NAME “ J As 

50 PR i NT " I NPiJT \ 1" ; PR I NT" OUTPUT i 2" J P'R I NT “ DEi ETE (3 
60 INPUTXION X GOTO 80» 160 
70 GOSUB 1030:A$<U)==" "TGOrO -<^0 
B0 INPUT"MESSAGE" 

90 Q'$i=As + ® 

100 GOSUB 1030 

110 IFA$(U)=‘'“THEN IAQ> 

120 PRiNT“COLL:SION '* J 

130TIi^U.TTTO YOU WANT TO OUERUAV •* J Yf IIFLEFTS (YS^DO-VT; 

150 GOTO 40 --- -- - 

160 GOSUB 1030 

170 IFAsiUl^" •'THENPRXNT“Er'FTY FIl E" {GOTO 40 
180 PRTNTAi(U) 

190 GOTO 40 
200 END 

1000 J PEN HASHING AN ALPHA NUMERIC >4 CHARACTERS 

1010 1 RET USING THE RND(X) FUNCTION OF MICROSOFT 

1020 1 

1030 U=RND<-.0012345) 

10T0 . REM CHANGE SEED IN KNOWN WAV 

1050 U=RND(-U/:0O) 

1060 : REM. FEED BACK AGAIN 

1070 F0 RZ = iTO 5 !X-ASC<MID$(A?fZ* 1 )) 

1080 t REM 1 

1090 IFX !'-'64TEihNX=X“64 

1100 J REM REDUCE ALPHA TO 1 TO. 26 

1110 IFX>47THEMX=X-47 

1120 : REM 1 TO 10 FOR NUMERICS 

1130 FORR==1TOX1U=RND( 1) iNEXTR 

11H0 J REM GET X'th RANDOM NUMBER 

1150 y=RND(-U)lNEXTZ 

U60 J REM PuACE BACK AS SEED 

1170 U=!NT (U*10000)“1000 *INT( 10«U) 

1180 : REM T.AST ONE AS INDEX 

1190 PRINT!PRINT 
1200 RETURN 


HEN 40 


BY 

BASIC 
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Speed 65U I/O with Second Buffer 

By l£e Conyers, Reston, VA 22090 


(Eaitor's Note: You're posting a 
series of transactions to a general 
ledger. With the standard 65U you have 
only one buffer, so every time BASIC 
corpletes one account it must dump the 
contents of the buffer back to the disk 
and read in part of another file. Slow! 
Imagine the disk activity if you have to 
post 500 transactions to 100 different 
general ledger accounts! 

Lee's program reads the general ledger 
account into the 65U buffer, then reads 
the transactions into a second buffer. 
BASIC reaches the general ledger file 
through ^annel 8 (fastU, and the 
transactions through memory I/O, Device #4 
(fast!). These fast read/update/write- 
to-memory operations are interrupted only 
occasionally by disk I/O operations. 

l^e's pr^ram is being added to the 
OSIO Disk Library, so we are printing only 
the highlights of it here, to show how the 
new buffer is added and how it is reached 
through Device #4, If you use OSI's 
OS/DMS, you'll notice i^en you get Lee’s 
program that he uses a much more detailed 
header. At the beginning of each file he 
lists the offset of the beginning of the 
data, the current number of records, the 
maximum number of records, record length, 
nunber of variables in each record, 
whether the variables are integer, 
floating ^int, or string, upper and lower 
control limits for numerical variables, 
etc. 

A bit of time spent studying this 
program in its original form should be 
good for the soul of every 65U programmer. 

Just one more note: You don’t have to 
worry about the USR-X routines Lee 
mentions, lliey're built into OS-65U.| 
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speed freak, I was happy to have 
my C3-Om upgraded to 2 Mhz. ThSfe to 
Cofmiunity Compters of Arlington, Va. for 
^ excellent j(±). Now interpretive BASIC 
is not so slow anymore. But disk buffer 
contention is still awful with OSI's 
straight BASIC file access methods. 

Buffer contention occurs VNhen you have 
two or more files open at a time, each 
experiencing frequent I/O, and having to 
share 65[J's single buffer, ^plications 
requiring heavy I/O can have severely 
reduced throughput due to disk buffer 
contention. It would be great if 65U could 
allocate a buffer for each OPEK'd file. 

But at 3584 bytes per buffer, you can see 
that memory would be gobbled up quite 
^ickly. A desir^le alternative might be 
if the user could allocate buffers of a 
predetermined size, one for each channel 
opened, with 65U managing the file 
housekeeping. Unfortunately, I don't think 
65U-is that flexible, ■'"^’se^s that if a 


user ventures into "extra buffering" he is 
saddled with a very burdensome file 
housekeeping chore. You will see what I 
mean in the example program. 


Well, I finally struggled through the 
process of allocating an additional 65U 
buffer, loading it via the 65U disk I/O 
USR(X) routine, and retrieving the data 
with memory I/O (INPUr#4}. I acknowledge 
and thank Jim Sanders of Vienna, Va. for 
invaluable information on the 65U input 
distributor enabling the INPUr#4 technique 
to work (for me). 


I am sure that most of you are tired of 
reading COTiplaints about OSI's documentation. 
Nevertheless, I'll complain here anyway. 

Ihe 65U manual has got to be one of the 
lousiest pieces of docunentation ever 
polished for a major software implementation. 
Trie writer{s) certainly must have assumed 
that the readers participated in the design 
and developnent of 65U. It was pure agony 
mplementing seme of the routines contained 
in my program that follows, i read the 65U 
manual many times over. I even studied the 
65D3 and 65D2 systems manuals trying to 
infer how to use similar features in 65U. 

continued on neset page 




Why didn't OSI write in the 65U Tnanual that 
if you cross a track boundary during one 
execution of USR{X) disk I/O your program 
gets blown away? 

The following program "MEM-IO" 
illustrates several techniques in 65U and 
BASIC: (1) allocating memory for a second 
65U buffer, (2) setting the input 
distributor for memory INPOT, (3) reading 
65U data files via USR{X), and (4) 
ocmbining a set of routines to test and 
debug I/O code before installing it in live 
applications. This program is the same one 
I used in developing ray own general ledger 
system. Consequently, you will see sane 
strange code that comes from ray personal 
data base file manager. I will only 
highlight the code unique to the techniques 
mentioned above. 

Line 16 reserves the second disk buffer 
in high memory. One 65U track is 3584 
bytes. 

Line 530 sets the input distributor for 
menory input via device #4, 

Line 590 instructs the file read loop to 
skip records containing a "deleted record" 
indicator {*). 

Line 19000 is a subroutine which dumps 
key variables to the console. These 
variables are primarily parameters 
controlling the disk I/O activity. 

Line 19100 is a subroutine that dumps 
your second 65U buffer to the console. It 
displays exactly vrtiat got transferred from 
disk to your buffer. 

Line 35000 is a subroutine to read one 
record from your second 65U buffer. 

Line 37000 is a subroutine to get file 
header data on the file to be read via 
USR(X}. Critical data is the file offset, 
nunber of records, and record length. 

Line 38000 is a subroutine that does 
most of the variable initialization work to 
execute the techniques. Some key variables 
are; AD - disk address of file's first data 
record; SZ - size of the disk file in bytes 
(informational purposes only to ocmpare to 
the directory figures); BM - second buffer 


msnory location in RAH; TB - total bytes to 
transfer; RT - nunber of records that can 
be transferred to the second buffer in a 
single block; NT — the number of transfers, 
or rather blocks, required for the 
particular data file. 

Line 39000 is a subroutine to control 
one of any of NT transfers. Here RE is the 
nunber of records transferred in the 
current block. Note that RE controls the 
read loop in line 550. Pay close attention 
to the conmented code that manages 
transfers w^ien track boundaries must be 
crossed to get the entire block of records. 
In essence, you execute two USR{X) 
transfers, or get blown away. 

Line 39160 resets the memory inpxit 
pointer for INPUr#4 to.the beginning of 
second 65U buffer. This pointer must be 
reset after each new block of data is 
loaded to the buffer. 

Line 39200 is a subroutine to control 
the execution of USRCX), . , 

Line 62000 is a subroutine that enables 
you to dump any block of RAM to the line 
printer(#5). 

The subroutines at lines 19000, 19100, 
and 62000 are very useful to see what has 
happened after the program stop>s. For 
testing I STOP with line 710. Then using 
BASIC's immediate mode I execute the 
subroutines as needed to review transfer 
operations. 

To modify "MEM-IO" to operate on one of 
your 65U data files you will probably have 
to modify lines 500-505 and subroutine 
37000. Subroutine 38000 needs data file 
information provided by subroutine 37000, 
sp^ecifically file header offset, current 
nunber of records, record length, and 
channel 8 control block information (for AD 
& SZ). Note that I have specified the data 
file to reside on drive B, and that drive B 
is the last active drive spjecified for 
USR{X) to read. 

Finally, I have submitted my program to 
OSIO to be added to the 65U exchange disk. 

I hope this program becomes as useful to 
you as it has been for me. 

I£E CONYERS 
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10 REM EXCE3^PTS PHDM MEM-IO BY LEE CONYERS. EtTTIRE PRDC3RAM IS IN 

11 REM OSIO PROGRAM EXCHANGE. THIS ILLUSTRATES SECOND BUFFER. 

16 POKE 133,176 : CIEAR : REM REDUCE MEMORY TO SET UP BUFFER 
530 POKE11668,9: REM SETT I/O DISTRIBUTOR FOR MEM I/O INPUT 
590 IFE8$="*"QarO 


19000 REM VARIABLE DUMP 
19100 REM DUMP BUFFER 

35000 REM READ A RECORD FROM SPECIAL BUFFER 
35010 INPOT#4,E8$;FORK=1TON8V:INPUT#4,22${K):NEXTK 
35020 RETURN 

37000 REM OPEN TRANSACTION FIIE ON CH 8 

38000 REM INITIALIZE ALL UNIQUE PARAMETERS 

39000 REM TRANSFER BLOCK OF RECORDS TO SPECIAL BUFFER 

39010 RRC8R-TR: REM COMPUTE TOTAL BYTES TO TRANSFER 

39020 IFRR>=RTTHENNB=RT*R8L:TR=<rR+RT:RE=RT:GCTO39035 

39030 NB=RR*R8L:TR=TR+RR:RE=RR 


39035 RA=BM: rEM 
39040 S5=INT(AD/BF): REM 
39050 S6=INr({AD+NB)/BF): REM 
39060 IFS5=S6Gar039140: REM 
39070 S7*(S6*BFJ-ADi REM 
39080 S8=(ADfNB)-(S6*BF): REM 
39090 NB=S7! REM 
39100 C3OSUB39200: REM 
39110 AD=AD+NB: REM 
39120 RA=RA4«B: REM 
39130 NB=S8: REM 
39140 aOSUB39200; REM 
39150 AD=ADtNB: REM 


SET RAM ADDRESS 
TRACK TRANSFER BEGINS IN 
TRACK TRANSFER ENDS IN 
NO TRACK CROSSING 
BYTES FIRST TRANSFER 
BYTES SECOND TRANSFER 
ASSIGN TRANSFER BYTES 
EXECUTE TRANSFER 
ADJUST DISK ADDRESS 
ADJUST RAM ADDRESS 
ASSIOSI TRANSFER BYTES 
EXECUTE TRANSFER 
ADJUST DISK ADDRESS 


39160 POKE11657,0:POKE11658,178:BK=BK+1 


39170 RETURN 


39200 REM ^ DISK I/O TRANSFER VIA USR(X) ' ' ' ' 

' 39210 DA=AD:DH=INT(DVHH):BM=DA-DH*HH 
39220 DM=IWr(i»1/HM) :RM=RM^DM*HM 
39230 DL=INT (R^^L): RM=RM-DL*HL 

39240 POKECB+1,RM:POKECB+2,DL:POKECB+3,DM;POK£CB+4,DH 
39250 POKECB+5,NB-INT(NB/Q}*Q:POKECB+6 , INT(NB/Q) 

39260 POKECB+7, RA-INT ( RVQ ) *Q: POKECB+8 , INT {RA^ ) 

39270 PW=0:Eft=USR(RH):IFRW<>0THENSTOP 
39280 RETURN 

62000 REM MEMORY DUMP UTILITY 
62010 GOSUB 42602 {NOT SHOWN HERE) 

62020 INFUT#CD%,"Begin memory du[np";B 

62030 INPUr#CD%," End marory dump";E 

62040 PRINr#CD%,'’Tum on printer, and "jiGOSUBO 

62050 PRINT#PD%,"MEMORY DUMP UTILITY: "fB; "THRU" ;E:PRINT#PD% 

62060 FORX4=BTOe:X5=X5+1 :DX(X5)=PEEK(X4) 

62070 IFX5<20QOrPO62200 
62080 PRINT#PD%,X4-X5+1;TAB(8}; 

62090 FORX5=1T020:DOC$=MID${STR$(LOC(X5)),2) 

62100 IFLEN{LOC$)<4THENLOC$=" "+L0C?:000062 100 
62110 PRINT#PD%,IjOC$;:NEXTX5 
62120 PRINr#PD%,TAB(100); 

62130 FORX5=1TO20 

62135 IFLOC(X5) = 13THENLOC$="'"":acrrO62180 
62140 IFLOC(X5)<32THENLOC$=".":QOTO62180 
62150 IFLOC{X5)>125THENLOC$=".":QOI062180 
62170 L0C$=CHR${L0C(X5)) 

62180 PRINT#PD%,LX$;:NEXTX5 
62190 X5=0:PRINT#PD% 


62200 NEXTX4 
62210 RETURN 
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OS-65D Notes 

by Joe Klrshner 


DATA OJ PROGRAM TRACKS 

Although I believe that putting the 
buffers on the bottofn is a waste of track 
space, leaving some space below the 
prograin can actually save track space. 
The reason that this is so is because 
occasionally you have a program that 
requires only a relatively few bytes of 
data, and you have to allocate a lA^^ole 
track for it. On the other hand, the 
program rarely fills exactly an integral 
number of tracks so that there may be 
space on your program tracks that could 
be used for data. 

If the bottom of memory is moved up, 
say one or two pages {256 bytes per 
page), and data is stored below the 
program, it will be saved along with the 
program under the program file name. 
(Data stored above the program is NOT 


INTERNAL AND EXTERNAL FIXES 
For convenience of discussion, 
define an internal file as one 
entire contents can be held in inter 
memory simultaneously. Conversely, 
external file is one that cann 
Although much of the previous discuss 
on internal files is also applicable 
external files, in holds entirely o; 
for internal files. The handling 
external files is somev^at more conip’ 
so that we will cover only a little 
what_ is possible, but hopefully enoi 
to illustrate the use of 65D for lai 
files. ...V 

Probably the easiest method is 
set up two files, each as long as 1 
desired file. Two files are neec 
because every time changes, additic 
and/or deletions are made, the file mi 
be transferred frcm the old file to t 
new one. Although this means t-RAt- if 


in the same way as you use the 
?£Cr FILE to put buffers under a 
if you forgot to do so (and if 
' insiSt - - on ^ putting ^ your buffers 
neath), you can pjt space under your 
■am for data. You then set the 
;ers of DEVICE #5 (raesnory) to the 
;ss vt^ere the program usually begins, 
As^ I have previously indicated, 1 
I it convenient to condense those 
•ties I found useful into a single 
vshich takes up four tracks. The 
versions of this file include the 
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continued from previous page 

30020 INPOT#S,I^*00$,IN|' 

30030 DISK OPEN,7,pU$ 

30040 DISK OPEN, 6 ,IN$ 

30070 FC« X»1 TO N 
30080 INPOT# 6 ,A$,B$,C$,D$ 

30090 GOSUB 1000 TO EDIT RECORD 
30100 PRINT#7,A$:PRINT#7,B$ 

30110 PRIMr#7,C$:PRINT#7,D$ 

30160 NEXT X 

30170 DISK CIjC^E, 6 :DISK CIjCSE-7 
30180 PRIIsrr#5,N:PRINT#5,IN$ 

30190 PRINT#5,OU$ 

Note that parent and ciiild are 
interchanged at output with reflect to 
Ir^xjt. That is, suppose my two files are 
named FII£A and FILE1 and that I 
initially designate CX]$=FILEA and 
IN$*FILE1. 

When the names are written to 

D^CE#5 (Lines 30180 and 30190), FIIEA 
will be written last, so the next time we 
ii^t (LINE 30020), OU$ will be 
designated as PII£1 and IN$ will become 
FUm. ^suaied that BASIC has been 

moved 15 ) so that these data stay with the 
If this has not been done, a 
separate one track file must be set up 
instead for these data). 


Because the number of records, 
not sav^ on the same traidc as the output 
file, It is not necessary to know.';* 
before outputting as we did in the cases 
of Internal files. If we add records 
the file in the method we are discussing, 
we _ smelly keep tr^ of the number and 
Wite it to DEVICE#5 after we have 
finished adding to the file. 

CORRECTICM OF A BOOBOO 
I have a note fron Mike Anderson on 
^ error in the blank removing part of 
his program which I included in my Mar 81 
OTli^. Inasmuch as I inadvertently 
include the blanks in lines 
5065 and 5080, they will not, of course, 
be removed. The first part of those lines 
should read: 

_ 5065 IF LEPT$m,1)=" " THEN _ 

5080 IF RIGfcrr$(T$,1)»" " THEN _ 

^it. progr^ that I am using to 

write column changes the number of 

s^ces in the process of right justifying 
the_ i .regardless gcsf,, the 

nutoer of spaces appearing between the 
quotes there should be exactly one space 

quotes iri:iines^5065 

ana bOaO* 


continued from page 1 

have conpleted (a conversicsi of another 
BASIC program) ran 40 times faster than 
the original, and would probably have nai 
even faster if I had taken full advantage 
of the features of jtjte ooinpi^r. 

(2) I found Pegasus ver^^asy to deal 
with. They answered ny que^^Mi within a 
week, I*m used to havir^ tc>^feit,*.mont 
or so for help of this kind.". 

(3) Pegasus has added sirnie _ 

that can be used by the canpiler. You can 
initialize the values in a DIM statement 
at ccmpile time. You can specify an 
address in memory for the vadues in the 
array to be stored. GOSUB can specify an 
address in memory of a machine language 
progran, Pegasus added a "KKILE" 
stat«nent. You can access the A, X, and Y 


That Compiled Basic 




registers of the CPU direcUy to put data 
in or retrieve it. 

(4) Pegasus plans to come exit with 

future vhich will 
5 , of the BASIC cormnands. 

ssiem of the I^asus 
er is that it's a lot liJce 
^ ily language program tajt 
write and much, much easier 
o miss the strir^ functions 
but, so far, I have been able to do 
witlx>ut them; besides, since you can use a 
regular BASIC program along with the 
ocmipiled “FBASIC", you can use the string 
fimcticwis to a degree, 

I can hardly wait for the new, expanded 
versicxis of FBASIC to come out. It’s well 
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Chapter Meetings 


The VA/DC/^ OSIO group meets on the 
first Tuesday of each mcnth at 7:30 p.m. 
at the Walter Johnson High School, 6400 
Rock Spring Drive, Hcckville, MD. 

^ meeting, a Pascal Panel 
^11 be conducted by David Morganstein, 
Brian Goodhart, and Marc Steiglef, all 
experienced Pascalers. Future meeting 
topics include OS-CP/M, BIZ-2, and 
cassette systems. 
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